README.md (1)

398-398: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Inconsistent dimension documented for Google AI.

Line 398 still states "Google AI 768d" but this PR changes Google embeddings to 3072 dimensions with gemini-embedding-2-preview. This should be updated for consistency.

📝 Proposed fix

-> **Note:** Each provider uses different embedding dimensions: OpenAI 1536d, Ollama 1024d (or 768d for v2-moe), Google AI 768d. Use the matching schema: `setup-db.sql` (OpenAI), `setup-db-ollama.sql` (Ollama 1024d), `setup-db-ollama-v2.sql` (Ollama 768d), or `setup-db-google.sql` (Google AI). You cannot mix providers without re-embedding all documents.
+> **Note:** Each provider uses different embedding dimensions: OpenAI 1536d, Ollama 1024d (or 768d for v2-moe), Google AI 3072d. Use the matching schema: `setup-db.sql` (OpenAI), `setup-db-ollama.sql` (Ollama 1024d), `setup-db-ollama-v2.sql` (Ollama 768d), or `setup-db-google.sql` (Google AI). You cannot mix providers without re-embedding all documents.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@README.md` at line 398, Update the README sentence that lists embedding
dimensions so Google AI is shown as 3072d (matching the new
gemini-embedding-2-preview model) instead of 768d; also ensure the referenced
schema name setup-db-google.sql remains correct or note if a new schema (e.g.,
setup-db-google-3072.sql) is required so readers know which DB schema to use
when using gemini-embedding-2-preview.

scripts/setup-db-conversation-google.sql (1)

11-37: ⚠️ Potential issue | 🟠 Major

Existing databases upgrading from other embedding providers won't be migrated to 3072d

CREATE TABLE IF NOT EXISTS at lines 11 and 27 only affects fresh installs. If users upgrade from setup-db-conversation-ollama.sql (1024d) or setup-db-conversation.sql (1536d), existing conversation_sessions.summary_embedding and conversation_turns.embedding columns retain their original dimensions. The TypeScript callers in src/db/conversation-search.ts will attempt to inject 3072d vectors into mismatched columns, causing runtime errors. Add explicit migration steps to handle provider switches.

Suggested migration pattern

 CREATE TABLE IF NOT EXISTS conversation_turns (
   id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
   session_id UUID NOT NULL REFERENCES conversation_sessions(id) ON DELETE CASCADE,
   role TEXT NOT NULL CHECK (role IN ('user', 'assistant', 'system')),
   content TEXT NOT NULL,
   embedding VECTOR(3072),
   turn_index INTEGER NOT NULL,
   token_count INTEGER,
   metadata JSONB DEFAULT '{}',
   created_at TIMESTAMPTZ DEFAULT NOW(),
   UNIQUE (session_id, turn_index)
 );
+
+-- Upgrade existing installs from other embedding providers.
+-- Existing vectors must be re-embedded after this change.
+ALTER TABLE IF EXISTS conversation_sessions
+  ALTER COLUMN summary_embedding TYPE VECTOR(3072)
+  USING NULL;
+
+ALTER TABLE IF EXISTS conversation_turns
+  ALTER COLUMN embedding TYPE VECTOR(3072)
+  USING NULL;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-db-conversation-google.sql` around lines 11 - 37, Existing
installs won't have their conversation_sessions.summary_embedding and
conversation_turns.embedding columns migrated to VECTOR(3072), so runtime errors
occur when TS code in src/db/conversation-search.ts writes 3072d vectors; add an
explicit migration in the DB setup that detects and converts older-dimension
vector columns (from 1024 or 1536 to 3072) instead of only using CREATE TABLE IF
NOT EXISTS in setup-db-conversation-google.sql. Implement the migration by
adding steps to the SQL script (or a new migration script) that: check current
column dimension for conversation_sessions.summary_embedding and
conversation_turns.embedding, create a temporary VECTOR(3072) column, copy
existing vectors into it (padding/truncating as needed), drop the old column,
and rename the temp column to the original name; apply the same logic when
switching from setup-db-conversation-ollama.sql or setup-db-conversation.sql so
the DB columns match the 3072d expected by the code.